home *** CD-ROM | disk | FTP | other *** search
/ AOL File Library: 2,801 to 2,900 / aol-file-protocol-4400-2801-to-2900.zip / AOLDLs / C++ Files Library / CW CDEV Framework / CW CDEV Framework 1.1.1.sit / CW CDEV Framework 1.1.1 / Usage Notes < prev    next >
Text File  |  1995-05-16  |  4KB  |  29 lines

  1. 05/16/95
  2.  
  3. Usage Notes
  4.  
  5. Since version 1.0 was released, several users have sent me suggestions, problems and comments.  Those thing that I could address and/or fix, I did and those that I can╒t or are unique to individual development situations I will try to address in this document.
  6.  
  7. Problem:  CDEVs compiled with the  framework leave a  ~65K pointer in system heap after it is closed.
  8.  
  9. Yes it does and it has to do with the way the new operator allocates objects.  The default method for allocating objects in MW C++ is to create a ╥pool╙ of memory from which all objects are then allocated.  The benefit of this method is that it cuts down on memory fragmentation.  In an C++ application this is no problem since the memory pool is created in the applications memory zone and is automatically disposed of when the application terminates.
  10.  
  11. Unfortunately, things get a bit more complicated when dealing with code resources that grab memory from the System heap.  When the CDEV (or any code resource) creates its first object, the memory pool is set up in the System heap.  As with applications, all other object allocations are taken from this pool.  When the CDEV (or code resource) closes, the pool is NOT released.  The new operator is depending on the heap being destroyed to recover that memory.  In fact, every time the CDEV is opened and its objects created another memory pool is created.  Over time this could amount to a serious memory leak every time the CDEV is opened.
  12.  
  13. So what can you do to prevent this leakage?  You need to alter the way that the new operator creates its objects.  Instead of creating a pool you want it to create the objects individually using NewPtr().  While this could lead to system heap fragmentation, CDEVs are generally small enough so that this is not too great a concern.
  14.  
  15. MW has made it easy to change the way that new allocates objects.  You╒ll need to locate the runtime library project CPlusPlusA4.  Open the project and then open the file called New.cp.  At the top of the file are some defines.  You need to locate the one called NEWMODE.  The NEWMODE define tells this library how to allocate objects with the new operator.  If you haven╒t changed it already it should still be defined to be NEWMODE_FAST or NEWMODE_NORMAL.  You want to change it to NEWMODE_SIMPLE.  NEWMODE_SIMPLE uses NewPtr()/DisposePtr() to create and delete objects instead of the memory pool method.
  16.  
  17. Your NEWMODE define should now look like this:
  18.  
  19. #define NEWMODE NEWMODE_SIMPLE          // mode used to compile this file
  20.  
  21. After making this change, recompile this library using ╥Make╙ and your done.  Now recompile your CDEV project so that it uses the new CPlusPlusA4.lib file.  The leakage problem caused by the new operators memory pool should be gone.  You can use MW╒s ZoneRanger to confirm this.
  22.  
  23. Problem:  Multi-segment CDEVs compiled with the framework crash
  24.  
  25. Although I have not had this happen to me personally, Devon Hubbard reported that his C++ multi-segment cdev kept crashing on him.  After a bit of poking around he determined that the virtual method table used by his cdev framework object was getting trashed.  A bit more poking and some Q & A with Metrowerks revealed that C++ code resources having virtual functions could have problems if the main code resource became unlocked and was moved.  This would indeed trash the virtual tables that the C++ object used.
  26.  
  27. The solution to the problem is to create a main cdev resource in C that in turn loads, locks and calls the C++ code resource.  The result of his efforts is a Metrowerks project called Stub CDEV.
  28.  
  29. The CDEV.╡ project in the Framework folder is already preconfigured to correctly use the stub CDEV so no modifications to the project or source code are necessary.  The cdev Stub code resource can also be added to existing CDEV projects that use the Framework (pre 1.1.1) without making any code changes.  To find out how to use stub CDEV in existing CW CDEV Framework projects or for more info on stub CDEV in general, please read ╥About Stub CDEV╙ in the Stub CDEV folder contained in this distribution.  The Simple Sample CDEV in the Sample CDEV folder is also constructed using cdev Stub.